Apple, the Apple logo, and Macintosh are registered trademarks of Apple Computer, Inc.
Mac and OpenDoc are trademarks of Apple Computer, Inc.
Documentation
ODSemanticInterface/ODBaseSemanticInterface
ODBaseSemanticInterface is the public SOM class for Semantic Events. ODSemanticInterface is now a public utility class. This change occurred because ODSemanticInterface uses a C++ helper class and therefore and it won’t be compatible with DSOM. It represents one way of implementing a Semantic Interface extension. Parts are free to create their own subclasses of ODBaseSemanticInterface as well.
Parts wishing to create a Semantic Interface extension should subclass ODBaseSemanticInterface and not just ODExtension since ODBaseSemanticInterface contains some default behavior that all Semantic Interface extensions should have.
The names of these two classes will probably change to reflect their new roles.
Default event handlers/object accessors
The Semantic Events subsystem provides a set of default event handlers and object accessors that are called when the event handler or object accessor for a part fails. These are used to provide default implementation for parts so that part developers will not have to write the same code in every part and to allow access to scriptable parts that are embedded inside of non-scriptable parts.
The default event handlers are:
Class: kCoreEventClass; ID: kAEGetData—This handler will return the properties of a part that are known to OpenDoc.
The default object accessors are:
Container: null; Object: cPart—this accessor will return a reference to a part’s embedded frames.
Container: null; Object: cProperty—this accessor will return a reference to a particular part property.
Container: cPart; Object: typeWildCard—this accessor will return a swap token so that context switching to the embedded part may occur.
Standard token for embedded frame
Semantic interfaces for parts are optional -- parts that don't have semantic interfaces aren't scriptable, and they don't participate in the process of name resolution for semantic events, but otherwise they aren't limited in their functionality. And, thanks to standard part tokens, neither do they limit the functionality of other parts.
Normally, during the process of name resolution for semantic events, the Name Resolver iteratively cals upon the semantic interface of parts along the hierarchy of the object whose name is being resolved. However, if one of the parts along the hierarchy doesn't have a semantic interface, the Name Resolver isn't necessarily stuck. It knows, by itself, how to resolve references to parts by part name, part index, and part ID, and, whenever it resolves a reference of one of these types, it creates a token for the appropriate part that it expects all other scriptable parts to recognize. These tokens are in a standard form, with descriptorType cPart. The dataHandle field contains an ODFrame*.
In sum, during the process of name resolution, the Name Resolver needs a way to "tunnel through" parts that aren't scriptable. When it does so, it creates a token that other scriptable parts should know how to handle. So, if you're implementing a scriptable part, and you're writing object accessors that resolve references to objects contained by parts, be sure you recognize and handle tokens in the standard form.
New token format
Unlike in the application-centric scripting world, where your application owned all of a token, in OpenDoc, OpenDoc reserves a portion of the token for its own private information. The descriptorType of the token and a portion of the dataHandle are owned by OpenDoc. The descriptorType of a token is always equal to typeUserToken. Embedded in the dataHandle of the token is an ODDesc with its own descriptorType and dataHandle fields that may be used any way that your part desires. Thus, the OpenDoc model remains the same as the application-centric model in which the application has access to a descriptorType and a dataHandle field; only the access to the data is different. [I am being vague about where this ODDesc is embedded in the dataHandle. I am waiting for approval on some new API that will allow access to it without developer’s having to know the details.]
